Gold Medal Software 3/Gold Medal Software - Volume 3 (Gold Medal) (1994).iso/misc/tcpgid.arj/TCPIP.DOC

Text File | 1993-08-05 | 104KB | 2,404 lines

Comments:     Warning -- original Sender: tag was [e-mail]
From:         Dean Pentcheff <[e-mail]>
Organization: Univ. of South Carolina, Columbia

Subject:      Getting started with OS/2 networking using IBM's TCP/IP software

Document: ftp-os2.cdrom.com:pub/os2/2_x/network/tcpstart.txt
       or: ftp-os2.nmsu.edu:os2/2_x/network/tcpstart.txt

 Guide to getting started with OS/2 networking using IBM's TCP/IP software

  Recent Changes

 Aug 03 1993 Added 3c503 Netware+TCP/IP sample files from Roger de Reus.
             Added Appendix III on LaMail (thanks R. Walker!).
             Changed directories for CSDs, made fixes to unpacking hints.
             Added section on useful software to download.
 Feb 28 1993 Fixed advice for routed, FTP security (thanks, Andre Asselin!).
             Added some tuning ideas.  Added lprmon BUFSIZE caution.
 Feb 22 1993 Fixed phone numbers, added SLIP appendix.  Fixed year to 1993!
 Feb 02 1993 Added Netware appendix, tuning hints, other hints and insertions.

  Table of Contents (find sections by searching for the parenthesized number)

 (0) Purpose and introduction
 (1) Request for more information
 (2) Some terminology
 (3) Selecting parts of the IBM TCP/IP packages
 (4) Preparing to hook up to a TCP/IP network
 (5) Installing IBM's TCP/IP Package
 (6) Installing the driver for the network adapter
 (7) Initial tryout
 (8) Downloading CSDs (bug fixes)
 (9) A few reminders
 (10) Security concerns
 (11) Tuning your setup
 (12) Interesting TCP/IP software you can download
 (13) Good luck
 (A1) Appendix I: Coexistence of TCP/IP with Netware
 (A2) Appendix II: Supplementary information on SLIP
 (A3) Appendix III: Setting up LaMail


 ----------------------------
 (0) Purpose and introduction
 ----------------------------

 The purpose of this document is to:

 1) Orient someone who has heard a bit about networking on OS/2, but
 can't yet hold an entire conversation in three to five letter
 networking acronyms ("So, Bob, how's TCP/IP coming along today?" "Well,
 Jane, NFS if fine, but I'm having trouble with FTP."  "Have you
 installed the CSDs?"  "Yes, but can you ping over SLIP before sending a
 job to LPD?"....).

 2) Help a new networker install the IBM TCP/IP networking package and
 some of its more popular additional modules.


 I'm no networking pro, but I've managed to start a working network
 system using OS/2 and IBM's TCP/IP offerings.  It took me long enough
 to sort it all out.  I hope I can save someone else the trouble.

 I make no guarantees that the following is entirely correct!  It's
 based on my experiences.  PLEASE correct me by mailing me your comments
 if you find anything misleading or wrong.  Please send me additional
 hints based on your own experiences that you feel would be helpful to
 put into this document.

 -Dean
 --
 N. Dean Pentcheff
 Biological Sciences, Univ. of South Carolina, Columbia SC 29208 (803-777-8998)
 Internet addresses: [e-mail] or [e-mail]


 --------------------------------
 (1) Request for more information
 --------------------------------

 Please let me know of improvements I can make to this document!
 Notable gaping holes that I notice (hint, hint) are:

 1) Performance tuning - success stories and failure stories are
 both equally welcome.

 2) Other useful network software - surely some net.geeks have some
 nifty utilities and addons that make a networked OS/2 system more of a
 joy.

 3) Tricks and tips that you've discovered.


 --------------------
 (2) Some terminology
 --------------------

 TCP/IP is the name of a communications protocol - it defines a way for
 computers to chat with each other.

 (PC)TCP is a family of products from several vendors that use TCP/IP on
 a PC, generally under the DOS operating system.  Note that pc/nfs is a
 specific product marketed by SunSoft (the (PC)NFS name has been adopted
 as a generic name for that type of product).  (PC)NFS is not addressed
 in this document - you may have heard about it from DOS systems.  The
 programs described here do what PC/NFS on DOS does (and more).

 Ethernet is a specific hardware protocol for computer communications.
 For example, a 3Com 3C503 card is a (very cheap and popular, if not
 screamingly fast) Ethernet board for PCs.  Using it (and appropriate
 software) you can connect a PC to an Ethernet TCP/IP network.  TCP/IP
 is just one of many communication protocols that can run atop
 Ethernet.  For example, a Novell Netware network running the IPX
 protocol could run on the same Ethernet - same hardware, just different
 protocols.

 Token-Ring is another hardware protocol in common use.  IBM's TCP/IP
 package supports both Ethernet and Token-Ring network adapters.

 FTP is a "file transfer protocol" that runs on top of TCP/IP (there are
 implementations of FTP for pretty much any computer that can talk
 TCP/IP, making it a lingua franca for file exchange - it's not pretty
 but it works).

 Telnet is a defined way for TCP/IP-speaking computers to set up
 terminal sessions between each other so that you can actually log onto
 a remote computer and interact with your account there.

 SLIP stands for serial line IP.  It defines a way that you can
 connect to a TCP/IP network over a serial line (via a phone modem,
 for example).  Serial communications is slower than a direct network
 connection, but can sometimes be useful.  IBM's TCP/IP packages does
 support SLIP.

 CSD is IBM's word for a publicly distributed bug fix package.  Note
 that CSDs obsolete prior CSDs.  That is, application of any later CSD
 will take care of everything that was done by earlier CSDs.  You don't
 have to apply the whole chronological string of CSDs, just the most
 recent one.  God help you if you install an earlier CSD over a later
 one (IBM sure won't help you).


 ----------------------------------------------
 (3) Selecting parts of the IBM TCP/IP packages
 ----------------------------------------------

 IBM sells a bunch of pieces, many of which are optional, for TCP/IP
 networking.  Following is a brief summary of them.  Note that all of
 the following come with both 1.2 Mb 5-1/4" and 1.44 Mb 3-1/2" disks in
 the same package (you don't need to specify medium).

 -- TCP/IP Base Program (Part #02G6968).  Price: US$131.  You need this
 in order to use any of the other following parts.  It gives you the
 software to connect your Ethernet or Token Ring card to a network, plus
 a few character-oriented programs (Telnet, FTP, ping, etc.).  It's sort
 of equivalent to the public domain NCSA Telnet package for DOS.

 -- NFS Kit (Part #02G6970).  Price: US$95.  This gives your OS/2 system
 the ability to serve as both a client and a server for sharing disk
 space using Sun's NFS (Network File System) protocol.  In other words,
 you can mount disks over the network that are physically attached to
 other minicomputers or OS/2 systems as though they were attached to
 your computer.  Conversely, you can make parts of your OS/2 computer's
 disks available for sharing by others.  With this package (along with
 the Base Program), you've got the makings of a small local area network
 that can share disk space and printers.

 -- X-Windows System (Part #02G6980).  Price: US$95.  This gives your
 OS/2 system the ability to display output (and relay input) to X
 programs running on other computers.  X-Windows is a standardized way
 for programs (mostly on Unix-based systems) to put graphics on the
 screen and interact with the user.  X terminology is a bit peculiar:
 the program doing the work is called the "client"; the program doing
 the display is called the "server".  This package allows your OS/2
 system to be an "X server", but not an "X client": you can display and
 interact with X programs running elsewhere, but you can't run an X
 program on your OS/2 system and have its results displayed elsewhere.

 -- X.25 Networking (Part #?).  Enables X.25 communications from your
 OS/2 system.  I have no exposure to this product, so I won't comment.
 I assume you'll know if you need it.

 -- Source code and programming packages.  If you're ordering these you
 sure as hell don't need me giving you hints on what to do.

 And finally, where to order.  Peculiarly, IBM often seems unaware
 that they sell this product.  So far, people have had the best
 luck with calling: 1-800-IBM-2-YOU (1-800-436-2968).  Another IBM
 order line (1-800-IBM-CALL) apparently knows about the product
 but likes to charge you more money (?!).


 --------------------------------------------
 (4) Preparing to hook up to a TCP/IP network
 --------------------------------------------

 Once you have the TCP/IP base package, you can be a full-blown node on
 the Internet.  To do that, you _must_ contact a local system
 adminstrator on the network to which you will physically connect your
 OS/2 machine.  He or she must give you an Internet number.  Choosing
 one at random is unlikely to work and is exceedingly antisocial (since
 it may well disrupt others' use of the network).

 You can probably select your own cute name for your machine, unless
 there is an iron-fisted net administrator who enforces a naming
 convention.  As examples, our lab works on crab behavior, so our PCs
 are called "fiddler" and "cancer".  The last place I worked had a lot
 of people working on marine larvae, so they had "cypris", "zoea",
 "actinula", etc.

 When you decide on a name and send it to your Local Network Guru, also
 ask the following questions:

         What will my machine's full Internet name be (e.g.
         fiddler.biol.scarolina.edu for the machine at which I'm
         sitting)?

         What is my IP address (e.g. 123.234.221.112 as a totally
         fictitious example)?

         Is this network subnetted?  If so, what's the subnet mask
         (e.g.  255.255.255.0)?

         Is there a non-default broadcast address?  If so, what is it?

         What is the IP address of a default router for me to use?

         What are the IP addresses of three domain nameservers?

 And, before you start the software installation, do yourself a favor.
 Open up your machine and take a good look at the network adapter card.
 Write down any strap or switch options that are set.  You'll probably
 need them later when you do the software configuration of the driver
 for TCP/IP.


 -----------------------------------
 (5) Installing IBM's TCP/IP Package
 -----------------------------------

 All the documentation comes with the Base Program.  The other packages
 just consist of a folder with disks.

 It is not initially clear how to proceed, so here's enough to get you
 going:

 Begin with the manual "TCP/IP Version 1.2.1 for OS/2 (Refresh):
 Installation and Maintenance".  You install the TCP/IP software first,
 then the specific driver software for your Ethernet or Token Ring board.

 There's a nice little configuration program called ICAT (Installation
 and Configuration Automation Tool).  As per instructions, stick in disk
 1 and run ICAT from an OS/2 command line.

 Push the "Install" button first.  It will give you the opportunity to
 install any/all of the options you've ordered (base package, NFS,
 X-Windows, X.25, and source packages).  Check off whatever boxes you
 want and feed disks as requested.  Go ahead and install everything
 you've got.

 Once everything has been copied to disk, push the "Configure" button of
 ICAT.  Now comes the fun stuff.  I'm assuming you have the
 documentation, so I'll just give you some hints based on what I did.
 There's a numbered list of 6 configuration things to do.  We'll run
 down the list.

 1.  Configure Network Interface Parameters.  You probably only have one
 Ethernet or Token Ring board in your computer, so you only have to fill
 in half this screen (the other half is for another board - and up to
 two more on a "Next Screen").  Your IP address is whatever was issued
 to you by your Friendly Local Network Adminstrator.  If he/she told you
 anything about a "Subnet Mask", enter it appropriately.  Leave
 "Broadast" and "Destination Address" blank (unless you've been
 explicitly instructed otherwise).  For that matter, leave the rest of
 the screen untouched unless told otherwise.  Don't forget to check the
 little "Enabled" box in the top left corner.  When done, press the
 "Menu" button to return to the main Configure menu.

 2.  X.25 Parameters.  You're on your own here (I haven't done this),
 but it looks straightforward - stick in your IP address.

 3.  SLIP Parameters.  This is if you're going to use a serial port for
 access, instead of a network adapter (SLIP = Serial Line Internet
 Protocol).  Fill in the IP address, and the rest is like setting up the
 dialer in a communications program.

 4.  Automatic Starting of Services.  Again, the following are
 reasonable defaults if (a) you haven't been told otherwise; and (b) you
 have the software involved.

         DO enable the inetd super server - this is one program which
         runs all the time and spawns off some of the other network
         service programs on an as-needed basis.  This way they don't
         all have to be started at once.

         If you want yourself or others to be able to Telnet into this
         machine, enable the Telnet server (BUT SEE NOTES BELOW - THIS
         CAN BE A REAL SECURITY RISK).  This does not influence your
         ability to telnet out of this machine to other machines.

         If you want to be able to access files on this machine from
         other machines using the FTP protocol, enable the FTP server.
         This does not influence your ability to use FTP on your machine
         to access other machines.  (SEE NOTES BELOW - THIS IS A
         POTENTIAL SECURITY RISK).

         Unless you know otherwise, DO NOT enable TFTP.

         I lean towards not enabling rexec and rsh unless there's a
         compelling reason to do so.  THESE ARE A REAL SECURITY RISK.
         Again, this does not affect your ability to rexec or rsh from
         your OS/2 machine to other machines.

         If you are going to make a printer attached to your computer
         available to other computers (i.e. your machine will be a
         network print server), enable the lpd server.  NOTE: To prevent
         lpd from printing a banner and control file before each
         document, set lpd to run in the "Foreground" (not via inetd),
         and type in "-b -c" (without the quotes) in the blank for
         arguments.  This is particularly important if you have a
         Postscript printer (since the banner and control files are in
         ASCII, not Postscript, they will mysteriously stuff the
         printer).

         If you've got the X-Windows stuff, enable it (leave the
         "Parameters" as it is).

         If you're into online typing to people, enable Talk, but
         honestly, why not just use the phone?

         Enable the NFS Server if you want other people to access your
         hard disk (SEE SECURITY NOTES BELOW).

         Enable NFSCTL if you want to be able to mount other machines'
         disks (but note that they must allow you to do so).

         If you have the IP address of a default router on your network,
         you can skip enabling the automatic routing server "routed".
         If you couldn't get such an address from the Local NetNerd, go
         ahead and enable the automatic routing server "routed".  (See
         some further remarks on this below in the "Tuning" section.)

         FINALLY, if you're going to receive mail directly onto your
         machine, enable "sendmail".  If you're already receiving mail
         on another machine, this is FAR more trouble than it's worth
         (in my opinion).  With the other software you've got, you'll
         easily be able to read your mail on another machine, so why
         bother with all the sendmail setup stuff (which is relatively
         fierce)?

 5.  Configure Services.  I'm going to give hints based on my slightly
 net.paranoid approach.  See the security notes below for some details.

         Put one and only one entry in the FTP Access Protection:
         anonymous.  (But see further notes in the "Security concerns"
         section below.)

         If you're doing X-Windows, X Host Authorization gets the name
         of the machine(s) on which your X "clients" (e.g. main
         programs) will run.

         In the X Client Display Variable, enter your OS/2 machine's IP
         address (or Internet name, whichever).  Not the name of the
         host to which you will be connecting, but this very OS/2
         machine's address.  Follow the IP address or machine name with
         ":0" (without the quotes of course).  For example, I entered:
         fiddler.biol.scarolina.edu:0

         Fill in the timezone in standard Unixoid format.  See page 95
         of the manual for some of the more popular timezones.

         If you will use another machine's printer, enter that machine's
         name and its printer's name.

         If you took my advice on rexec, enter nothing in the rexec
         username and password.

         Enter nothing in the password field for telnet (BUT SEE THE
         SECURITY NOTES BELOW).

         Enter your machine's name in the Hostname field (just the very
         first part of the name: "fiddler" in the case of
         "fiddler.biol.scarolina.edu").  Enter the rest of the name in
         the Domain Name field ("biol.scarolina.edu").

         Type in (correctly!) the IP numbers of the (up to) three local
         nameserver machines your Always Cheerful Network Adminstrator
         gave you.

 6.  Routing Information.  If you have the IP address of a default
 router, enter it here.  Follow the keypress instructions to insert an
 entry.  Toggle the "Route Type" field using space, leave "Route
 Destination" blank, type in the IP address into "Router", and leave
 "Metric count" at 1.  If you do _not_ have the IP address of a default
 router, make sure you enabled the "routed" daemon.  Then check below in
 the "Tuning" section to see how you can find out your default router's
 address later, insert it here, and dispense with "routed."

 When this is done, go ahead and "Exit" all the way out of the ICAT
 program, reassuring it that you really do want it to write this stuff
 to disk as it quits.


 -------------------------------------------------
 (6) Installing the driver for the network adapter
 -------------------------------------------------

 Once you finish with all that nonsense, you will realize that you
 haven't told the software anything about the network adapter you've got.
 Time to turn to the "LAN Adapter and Protocol Support Introduction and
 Configuration Guide".  Cram in the LAPS disk, and, from an OS/2 command
 prompt, start up the "LAPS" program from the floppy.

 The following discussion assumes you will be using a network adapter
 card (either Ethernet or Token-Ring).  If you will be using SLIP (IP
 over a serial line with a modem), I suspect things may be a bit
 different, but I don't know, I've never tried (as in: "Can you play the
 violin?"  "I don't know, I've never tried").  See Appendix A2 below for
 some supplementary information on SLIP.  I don't use it, so I haven't
 tested this, but give it a whirl.  For now, we'll continue to assume
 that you're using a network adapter card...

 First do the "install" to copy in the software.  Next, go to the
 configuration part.

 What you do is simple: pick one from column A and one from column B.  In
 fact, IBM has made it simpler still - there's only one choice in column
 B (but you still have to explicitly pick it).  Choose your network
 adapter from the Network Adapters list (select and "Add" it).  (If your
 network adapter isn't on the list, see the remarks a few paragraphs
 below here.)  Then choose the only choice (IBM TCP/IP) from column B.
 You've now declared that your network adapter number 0 (the first one)
 is of a particular type, and it will run TCP/IP.

 Now highlight the adapter name in the Current Configuration window and
 press "Edit".  Now's your chance to make sure that the hardware options
 on your adapter match up with the software's idea of them.  Change
 anything that needs changing.  When in doubt, leave it as it was.
 Notably, you should probably leave the "Network Adapter Address"
 blank.  That number is supplied by the board hardware unless you enter
 an overriding number here.

 Once you're done with the configuration, press "OK" and the proper
 configuration will be copied in.


 What if your network adapter isn't "supported"?  That is, you didn't see
 it on the LAPS list.  Odds are good that it really is supported.  First
 of all, check the documentation - your adapter may emulate an adapter
 that is in the LAPS list.  If so, you're home free.  If not, you need to
 get hold of an "NDIS driver" for your adapter.  There may be one on a
 disk that came with the card.  Alternatively, you may be able to find
 one on the ftp-os2.cdrom.com archive (see the section on downloading
 CSDs in this document to see how to access the archive).

 Once you've got the NDIS driver, you'll need to do a little hand editing
 of some configuration information.  The following description is edited
 from some advice posted to the Usenet group comp.os.os2.networking by
 Kai-Uwe Rommel ([e-mail]) regarding the popular
 3Com Etherlink III card (a very fast, excellent Ethernet card, by the
 way).  I haven't done this myself, so I don't know how easy it will be
 to adapt these instructions to other cards, but take a look at this and
 see how it goes...

         NDIS drivers for DOS and OS/2 come included with the Etherlink
         III card. I'm not sure if the LAPS install program of the TCP/IP
         package allows "other cards" to be installed, but otherwise
         simply install the Etherlink II drivers first. Then, before
         rebooting, copy ELNK3.OS2 from the Etherlink III driver floppy
         to the same location where ELNKII.OS2 is and replace ELNKII.OS2
         in config.sys by ELNK3.OS2. In the protocol.ini in \IBMCOM, add

                  ELNK3_nif
                 DriverName = ELNK3$

         right below the  ELNKII_nif  section and replace

                 Bindings = ELNKII_nif

         in the TCPIP_nif section by

                 Bindings = ELNK3_nif

         and it should work after rebooting. You may want to boot DOS and
         run the 3C509 program from the Etherlink III driver disk to set
         up the card to use an IRQ > 8 (i.e. IRQ 10, for example) and set
         the "client type" to a better suited one (you can choose DOS
         client, Windows or OS/2 client or server). If you install the
         Etherlink III in EISA machines, run the 3C509 program to switch
         the card into EISA mode (yes it has one although it is an ISA
         card) and use the EISA setup program and the config files on the
         Etherlink III driver disk to configure it. See Appendix E in the
         Etherlink III manual.


 ------------------
 (7) Initial tryout
 ------------------

 Are ya feelin' lucky?  Hope so.  Quit out of LAPS.  Do the standard
 OS/2 Shutdown.  Make sure your network adapter is actually plugged into
 a network.  Cross fingers and toes.  Start up OS/2.

 It will take much longer to boot as five zillion networking programs
 crank up.  Lots of them will put screens up as they come on.  Once
 things are up, you can minimize these screens.  Meanwhile, they will
 tell you of your progress.

 If things really choke and you don't get a boot, well, you knew the job
 was dangerous when you took it.  Get an OS/2 guru to boot from a floppy
 for you and REM out the line in "startup.cmd" that says "CALL
 C:\TCPIP\BIN\TCPSTART.CMD".

 Assuming things more-or-less come up, try things out.  First, from an
 OS/2 command line, try a ping to yourself.  In my case, that's "ping
 fiddler.biol.scarolina.edu".  You should get a series of one-liners
 once a second informing you that you've sent 64 bytes to yourself and
 received it.  Press Control-C to quit that.  If, after you enter your
 ping command, you get nothing (the command just hangs there), you've
 got a problem: you're unable to find yourself.  Check your machine name
 and Internet number using ICAT, and make sure your network adapter
 board is properly set up, and the correct parameters are set using
 LAPS.

 One thing you'll want to try (but DON'T) is to double-click on the cute
 little INETD icon.  Don't do it.  You'll get a textmode screen with
 Inetd's potential clients listed.  That's it.  No menus.  No nothing.
 It makes you feel like DOS is back.  Press Alt-Tab or Alt-Esc to get
 the hell out of there.  Memorize this, because one day you'll do it
 accidentally anyway.

 Try telnetting to your local host.  Try an FTP file transfer.  Once FTP
 file transfers work, I advise you to take the following step next,
 before doing much more playing.

 Note: unless you've started telnetd and/or ftpd (or have them set
 to start from inetd), don't try to telnet and/or ftp to yourself!


 --------------------------------
 (8) Downloading CSDs (bug fixes)
 --------------------------------

 My system almost-kinda-sorta worked (flakey is the word that comes to
 mind).  Following application of the bug fixes, it works very
 smoothly.  So, to avoid wasting time, apply the bug fixes early.
 Following is the scoop on how to do this.

 DON'T BE INTIMIDATED BY THE LENGTH OF THIS SECTION!  Because the CSDs
 change with time, this section is verbose to cover different
 contingencies.  It's really quite straightforward in practice.  Install
 the bug fixes - you'll be very happy you did.

 1.  For neatness' sake, make a subdirectory called "csd" (well, don't
 listen to me about it, call it "rosebud" if you want).  Do a "cd" to
 that directory (all this is done from an OS/2 command line).

 2.  Give the command:  ftp ftp-os2.nmsu.edu

 3.  If that doesn't work ("host unknown" or "network unknown") you've
 got a problem with domain name resolution.  MAybe routed.exe isn't
 running or you have a bad DNS nameserver entry?  Ignore that for now,
 but fix it later.  Try giving the command:  ftp 128.123.35.151

 4.  Log in as user anonymous, with your full login ([e-mail]) as
 password.  Yeah, you don't really have a user name ("joe") since you're
 on a single-user machine.  Make one up.  For my machine, for example,
 I might enter "[e-mail]" (without the quotes).

 5.  Give something like the following FTP commands (things in square
 brackets are my comments, not parts of the commands):

         binary
         cd os2/ibm/tcpip                [get to the directory with fixes]
         get tcpcsd1.exe                 [Base TCP/IP package patches]
         get tcpcsd2.exe
         get basecsd.doc                 [how to install Base CSDs]
         get nfscsd1.exe                 [if you've got NFS]
         get nfscsd.doc                  [how to install NFS CSDs]
         get pmxcsd1.exe                 [if you've got X-Windows]
         get pmxcsd.doc                  [how to install X-Windows CSDs]

 You may find that some of the CSDs have filenames ending in ".zip"
 instead of ".exe".  If so, do the following as well:

         cd /os2/2_x/archiver
         get unz50x32.exe                [Info-ZIP unzipper for unpacking[

 Quit from FTP with the following command:

         bye

 Of course, this will be out of date soon.  Just look for the most
 recent CSD packages in the directory and snarf them.  Likewise for the
 Info-Zip unzipper.  You should also check the directories "/os2/new"
 and "/uploads": new uploads go there first and may not have made it to
 the patches directory yet.  If there are several different CSDs for
 products you have, download them all.  Unpack them (see below) each
 separately on your machine and check the comments in the installation
 scripts for the latest date.

 6.  Unpack the suckers.  If you got the unzipper program, just run
 unz50x32.  It will unpack itself into the unzip program.  Each CSD
 release seems to be slightly differently packaged, so I'll just give
 some general guidelines here.  You can probably install them from your
 hard disk, without having to copy them onto floppies (though they are
 usually designed to be installed from floppies).  Make a subdirectory
 for each type of CSD (for example, I made subdirectories "base", "nfs",
 and "pmx") under the directory where you have the zip files.  Then
 unpack each bundle into its appropriate subdirectory.

 If the CSD filename ends in ".exe", things are easy: it will unpack
 itself into its component files.  For example, to unpack the Base
 packages, I'd do the following:

         mkdir base
         cd base
         ..\tcpcsd1
         ..\tcpcsd2

 If the CSD filename ends in ".zip", you have to explicitly use the
 unzip program to unpack the file.  For example (if the CSD files were
 called "tcpcsd.base1.zip" and "tcpcsd.base2.zip"):

         mkdir base
         cd base
         ..\unzip  ..\tcpcsd.base1
         ..\unzip  ..\tcpcsd.base2

 Normally, the unzipping leads to the creation of 5-50 updated programs
 and files, one of which is an installation script (ending in ".cmd").
 In some cases, the zip files will unzip into one or two monolithic
 ".exe" programs.  These aren't really standalone programs, but are
 self-unpacking zip files.  If, when you're done unpacking the first
 level of zip files, you only have one or two huge ".exe" files and you
 DO NOT HAVE ANY FILES THAT END IN ".CMD" (i.e. you don't have an
 installation script yet), check to see if the couple of huge programs
 are actually zip files in disguise.  To do that, run the listing
 function of unzip.exe.  For example, to check a hypothetical file
 "basecsd.exe", try running:

         ..\unzip  -v  basecsd.exe

 If the unzip program barfs, it's not a zip file.  If you get a nice
 listing of lots of filenames, you can unzip the archive by simply
 running the program.  For example:

         basecsd

 Don't do any of this fussing if there's a ".cmd" file in the directory
 from your inital unzipping - that's probably the installation script
 which will take care of the next level of unzipping for you.

 7.  Check the installation scripts.  I've found two types.  One is a
 pretty elaborate script that quite neatly checks your system out and
 installs the CSDs from the hard drive directory.  These longer scripts
 are over 100 lines long.  If there are just a few files that need
 copying, there may be a short script instead.  In some cases, these
 short scripts are "hardwired" to copy from the A: drive (tacky!).  A
 quick edit of any offending lines takes care of the problem.  For
 example, changing the line:

         copy 'A:nfsctl.exe' BASE'\bin\nfsctl.exe'

 to read:

         copy 'nfsctl.exe' BASE'\bin\nfsctl.exe'

 converts the command so that it will run from the hard drive instead of
 needing to be put on a floppy.

 8.  Now you've got your CSDs (bug fixes) on disk, ready to install.  You
 have to first REM out a couple of lines in your startup scripts, then
 reboot.  Otherwise, OS/2 will refuse to let you update programs that are
 currently running.  Using your favorite editor, edit your c:\config.sys.
 Find the line that runs CNTRL.EXE.  Insert REM (followed by a space)
 before it.  Save the file (as Plain Text, if you're asked).  I found
 that I also had to edit the file c:\startup.cmd and REM out the line
 that reads "CALL C:\TCPIP\BIN\TCPSTART.CMD".

 Now reboot.

 Why not do all this before even rebooting once?  Because applying the
 CSD depends on a lot of networking environment that is set up in the
 main config.sys file, so you've got to have booted with the networking
 stuff installed but REMed out for the CSD to apply properly.

 9.  If you're lucky, IBM will have included a "*.doc" file that will
 give you some hints on how to install each CSD.  If so, read the file,
 and read the hints in the next paragraph.  Between them all, decide how
 to install the CSDs.

 In the absence of an official "*.doc" file, you're on your own.  Each
 CSD has its own handy install script.  Go to each CSD's subdirectory
 and run the something-or-other.CMD file.  For example, for the Base
 Package it might be basecsd.cmd; for NFS it might be nfscsd.cmd; for
 X-Windows it might be installx.cmd (thanks for the consistency, guys).
 Or it may be called something new and exciting.  Basically all that
 these do is copy over a bunch of new versions of programs on top of the
 old ones.  As far as I can tell, they don't meddle with initialization
 setups.  [Late note on that - one of the newer CSDs does install a new
 xinit.cmd, but quite politely informs you that it is moving your old
 one to "xinitbak.cmd".]

 10. With your trusty editor, remove the REMs from config.sys and
 startup.cmd.

 11. Reboot OS/2 to a far less bugfull networking setup.

 12. Periodically check in at ftp-os2 for new CSDs.  Apply as above and
 they will overwrite whatever is needed to bring you up to date.  Note
 that later CSDs make earlier CSDs obsolete: each CSD is complete.  You
 do NOT need to install the whole chronological string of CSDs to get up
 to date.  The latest CSD will do everything that any earlier CSDs did.


 -------------------
 (9) A few reminders
 -------------------

 If you want to mount part of a Unix box's disk, the Unix machine will
 need an entry in its /etc/exports file describing what you're allowed
 to mount.  Similarly, your OS/2 system's \tcpip\etc\exports file will
 have to list systems you allow to mount your disks (SEE SECURITY NOTES
 BELOW).

 If you want to redirect printer output from your machine to an LPD
 program on some other machine, you'll have to start up an lprmon process
 for each of the printer ports you wish to redirect.  See the manual for
 the syntax.  The trick is where to put the startup commands.  If you
 don't mind seeing the lprmon windows appear at boot time, edit the file
 \startup.cmd and insert the command(s) there.  That's a better solution
 than putting them in \tcpip\bin\tcpstart.cmd, since tcpstart.cmd gets
 clobbered if you rerun ICAT to reconfigure your setup.  If you are going
 to edit your tcpstart.cmd file anyway (see the section below on tuning
 for reasons you might do that), go ahead and stick them into
 tcpstart.cmd.

 Note that there's a weirdness associated with lprmon: it apparently
 cannot monitor a port that has a larger-than-default buffer size.  So
 make sure that you check the PRINTMONBUFSIZE in your \config.sys.  For
 any port(s) on which you will run lprmon make sure that the buffer size
 is left on the default setting (134).  For example, a vanilla version
 should be: PRINTMONBUFSIZE=134,134,134


 ----------------------
 (10) Security concerns
 ----------------------

 You are now a node on the Internet (assuming you've hooked up to an
 Internet-worked network).  That means you have to be security conscious.
 You don't have to be an international bank to be chosen as a victim.
 There really are people out there trying to break into whatever
 computers they can.  You don't want to leave yourself open to that.

 Furthermore, if your computer is ever broken into, you stand a far
 better chance of getting sympathetic help if you didn't leave it wide
 open in the first place.  If I leave my door open and someone walks in
 and takes things, they are still doing wrong, but I'd be more likely to
 get sympathetic help had I locked the door.

 I will outline the approach I've taken to setting up our OS/2 systems.
 I AM NOT A UNIX OR NETWORK SECURITY EXPERT.  Just for good measure, I'll
 say that again:  I AM NOT A UNIX OR NETWORK SECURITY EXPERT.  I've done
 enough reading to know that (a) it matters; and (b) security holes can
 be very subtle.  So don't necessarily believe what I'm recommending.  I
 welcome comments (but I will not open a debate on the morality of
 computer breakins).

 1.  Enable Telnet but only with the real password option.  The default
 password option offered is very weak.  It requires a single password
 that is readable by anyone who has access to the system.  VERY WEAK.
 But, buried deep is a better solution.  On page 72-73 of the
 Installation and Maintenance Manual is the description of how to set up
 telnet to require a Unix-style password file.  Now, Unix-style passwords
 are far from hyper-secure, but they're better than a clear-text
 "password"!  Perversely, IBM doesn't provide you with a program to make
 the passwd file: you'll need to copy an /etc/passwd file from a Unix
 host.  But you've probably got a login on a Unix machine - you can use
 its password file.

 Follow the directions to install the passwd file and shuffle in a
 different version of the login.exe program on OS/2.

 In general, don't depend on any of the so-called "passwords" that appear
 in environmental varibles.  World-visible passwords are a (bad) joke.

 2.  Disable incoming FTP except for the very restricted "anonymous"
 account.  Your TRUSERS file should look like this:

         user:  anonymous
         rd:    c:\anonymous
         wr:    c:\anonymous

 Make sure to create the directory c:\anonymous.  Someone can stuff your
 system by filling disk's c:\anonymous directory with garbage, but that's
 relatively benign.  If that's a problem, remove "c:\anonymous" from the
 "wr:" field.  How can anyone FTP a file into your machine if you don't
 even let them have ftp write access to "\anonymous"?  With this setup, a
 really trusted user can have an entry in the Unix-style passwd file.
 Then she or he can telnet into your machine and run FTP on your machine
 to suck the file in.

 Don't have anything else in the TRUSERS file.  The idea of unencoded
 passwords is ludicrous.

 [Supplementary note added later:] Perhaps the above approach is a
 little harsh.  It turns out that FTP will not allow reading or writing
 of the TRUSERS file.  Hence, you _could_ put other entries into the
 TRUSERS file and an FTP-logged-in person couldn't pilfer the TRUSERS
 file itself.  NOTE however, that TRUSERS will be accessible to any NFS
 or Telnet users, so passwords there are still available.  You decide.
 Personally, it makes me too nervous.

 3.  Don't enable the rexecd server.  It depends on clear-text passwords
 in the environment or in the NETRC file.  People can Telnet in through
 the passwd-protected telnet, then execute the command.  Same goes for
 the rshd server.

 Come on.  Do you really want Joe Unwashed-behind-the-ears to be able to
 do "rexec yourmachine del c:\*"?  And then giggle a bit.  Yup, that
 could happen.

 4.  Don't enable the TFTP daemon "tftpd" unless you really need it for
 some obscure reason.  FTP does the job.

 5.  Vanilla NFS is well known to be full of security holes.  You'll
 notice the tight security demanded by the Unix host: give it a UID and
 GID number and that's who you are.  Cute.  I'd be very wary about giving
 write permission to my disk.

 REMEMBER: THERE ARE NO ACCESS CONTROLS ONCE SOMEONE
 HAS ACCESS TO YOUR OS/2 SYSTEM.  No files are protected from
 reading or deletion.  Once  someone is into your system, they can
 happily read any of your setup files in \tcpip\etc (which could [if you're
 naive] contain real live readable passwords).  They can also read your
 \config.sys and tcpstart.cmd files, in case they missed a password or two.

 The only people I want to have write access to my system are people
 who've passed the (really minimal!) test of having logged in past the
 Telnet-with-Unix-style-passwords.


 ----------------------
 (11) Tuning your setup
 ----------------------

 Following are a few hints and suggestions that may help your networking
 system work better.  Where I remembered, I've attributed suggestions to
 the people who suggested them.  In most cases, these suggestions
 appeared on the Usenet newsgroup comp.os.os2.networking.  I have edited
 many/most of these for conciseness and format, so I'm to blame if I've
 screwed them up (sorry).  My apologies to those whom I forgot!


 1. If you edit any of the installation scripts yourself, note that IBM
 uses an undocumented syntax.  They use "attrib file parameters" instead
 of "attrib parameters file".  This works fine unless you use 4OS2 (a
 command-line enhancer).  If you do, start up an unenhanced cmd shell
 first.  ([e-mail] (Helmer Aslaksen))


 2. After the initial thrill wears off, you'll wish there was some way to
 get OS/2 to stick all the networking windows into the Minimized Window
 Folder automatically at boot time.  Following is a scheme for doing so.
 The basic idea is to stop tcpstart.cmd from being run in the
 \startup.cmd script (running it as a "Startup" folder object instead)
 and get all the programs started minimized, instead of as normal
 windows.  ([e-mail] (Timothy F. Sipples),
 [e-mail] (Helmer Aslaksen), others)

         A) Edit \startup.cmd and put a REM in front of the line that
         runs the tcpstart.cmd script.  Add an "exit" to the end of the
         \startup.cmd file (if you want its window to vanish, too).  In
         fact (if nothing else is started in that file) instead of
         editing it, you can just move it to \startup.old and forget
         about it.

         B) From the desktop, open the "OS/2 System" object, then the
         "Startup" object within that.

         C) From the "Drives" object, open up directories until you have
         an icon view of the \tcpip\bin directory.  Click the right mouse
         button once on the \tcpstart.cmd script.  Using the resulting
         popup menu, create a shadow of the object, selecting the
         "Startup" window to be its location.  The reason for doing A-C
         is that things in the "Startup" folder start up late enough in
         the boot process that they start after the Minimized Window
         Viewer is in place.  Otherwise, you get icons across the bottom
         of the desktop (eeeeww!).

         D) Now edit the file \tcpip\bin\tcpstart.cmd.  Wherever you see
         a "start ..." line, change it to "start /min ...".  That will
         cause the programs to start minimized.  NOTE: Check this file
         again any time you run ICAT: your changes may get blown away
         so that you'll have to reinsert the "/min"s.

         E) For any line in tcpstart.cmd that starts "call ...", edit the
         script that gets called.  In those scripts, again change "start
         ..." lines to "start /min ...".  Check this also after running
         ICAT.

 3. Some of the networking software doesn't actually need to be run as a
 subprocess of a "cmd" process.  For these cases, rather than issuing a
 "start ..." or a "start /min ..." to kick them off, you can issue a
 "detach ...".  For some processes (ones that have certain requirements
 for interaction with keyboard and display), this won't work.
 Experiment with it, though, you can save some memory that way.  I've
 found that it works with lprmon, lpd (run standalone, not via inetd),
 portmap, and nfsd.  It does not work with telnetd.  I think it works
 with inetd itself, but if inetd starts telnetd for you, then telnetd is
 stuffed.  Hence, I gave up on inetd.  Others, you're on your own...

 4. If you have already put a default router's IP address into your
 configuration, you're probably not running routed.  If you are running
 routed, however, you may be able to discover what your default router
 is, insert its address, and stop running routed.  After you've been
 doing network things for a while (including pinging or ftping some
 remote sites), give the following command from an OS/2 command window:

         netstat -r

 Look for an entry that begins with "default".  You guessed it: use that
 IP address as your default router address.  Use ICAT to edit your
 network configuration: turn off "routed" and configure the default
 router's IP address into the Routing Information section.  (Routed
 information: [e-mail] (Andre Asselin))

 5. The networking software sucks memory.  If you have 8 Mb or less of
 memory, your performance will go down noticeably (but far from fatally)
 as OS/2 swaps things in and out more often.  Don't need the TELNET
 server?  Close it.  Don't need the FTP server?  Shut it down.  Don't
 need the TALK daemon?  Get rid of it.  Mailer unnecessary?  Leave it
 aside.  Only use X Windows occasionally?  Start up the PMX daemon "by
 hand" when you need it.  That said, we find that full blown TCP/IP does
 quite well in (true) 9 MB.  The extra megabyte appears to make all the
 difference in the world.  If you don't run with everything but the
 kitchen sink, 8 MB is viable.  The 2.1 release should improve on that
 even more [since IBM is making efforts to make the OS/2 base use up
 less memory].  Pay attention to cache sizes, by the way: a disk cache
 that is too large will actually decrease performance.
 ([e-mail] (Timothy F. Sipples))  Our experience is that
 beefing up our systems to 16 Mb made things run _far_ more nimbly: the
 near-continual disk grinding stopped and the agonizing pauses went
 away.


 --------------------------------
 (12) Interesting TCP/IP software
 --------------------------------

 There is a plethora of free software available on the Internet.  One of
 the largest repositories of OS/2 software is the machine:
 ftp-os2.cdrom.com.  Access it using anonymous FTP.  That is, connect to
 it using ftp (give the command: ftp ftp-os2.cdrom.com) and give the user
 name "anonymous" (without the quotes) when prompted for a user ID.
 When prompted for a password, give your email address.  See the manual
 entries on the FTP program for more details.  Also see part (8) of this
 document for an example of downloading some files using FTP.

 Following are some pointers to useful TCP/IP-oriented programs (and
 some other "indispensables") that can be downloaded from ftp-os2 or
 other archive sites.  The filenames are indented under the names of the
 directories under which they are found on ftp-os2 - locations may vary
 on other archives.  A "*" for the filename indicates that there are
 several files in that directory that are relevant.

 pub/os2/all/info/faq/
         *             The OS/2 Frequently Asked Questions (with answers!)
 pub/os2/ibm/ews/
         gopher.zip    PM client for the Internet Gopher Client
         goserv.zip    A Gopher Server protocol for OS/2 2.x
 pub/os2/2_x/network/
         nistime.zip   Update time/date from NIST Internet server
         os2gofer.zip  Gopher client for OS/2 PM (requires VREXX & TCP/IP)
         os2nosv4.zip  TCP/IP for OS/2 (via SLIP) - text-based
         passwd.zip    IBM TCP/IP passwd file maintenance utilities
         slip20b1.zip  Better performing SLIP for IBM TCP/IP 1.2.1
         tcpstart.txt  This document you're reading now!
         tn_enh11.zip  Enhancement for IBM OS/2 2.0 telnet daemon
         wsos21.zip    Novell Netware Requester 2.01 for OS/2, Disk 1 of 3
         wsos22.zip    Novell Netware Requester 2.01 for OS/2, Disk 2 of 3
         wsos2d.zip    Novell Netware Requester 2.01 for OS/2, Disk 3 of 3
         nsd202.zip    Novell Service Diskette (NSD #2) for WorkStation Kit
 pub/os2/2_x/network/ndis/
         *             NDIS drivers for many Ethernet cards
 pub/os2/all/network/ndis/
         *             NDIS drivers for many Ethernet cards
 pub/os2/ibm/tcpip/
         *             Home of "official" IBM bug fixes to TCP/IP
 pub/os2/2_x/patches/
         *             Home of more CSDs and bug fixes
 pub/os2/2_x/unix/unixutil/
         elvis172.zip  Elvis 1.7, a vi clone (for Unix devotees)
         xfeel11.zip   A utility to make PM behave like X-Windows


 --------------
 (13) Good luck
 --------------

 That's about it for now, folks.  Read the IBM manuals - they're actually
 not too bad.  Not hold-your-handish, but most of what you need is
 (somewhere) in there.

 Best of luck with networking.  Maybe we'll ping each other one day...


 ---------------------------------------------------
 (A1) Appendix I: Coexistence of TCP/IP with Netware
 ---------------------------------------------------

 Personally, it's hard for me to believe, but apparently there's this
 other networking scheme out there by this little startup called
 Novell...  I haven't needed to interact with a Novell network, but lots
 of people do.  I've collected some of the postings from the Usenet
 newsgroup comp.os.os2.networking that address this issue.  I hope that
 they will help you get things working if you need to access TCP/IP and
 Novell.

 I have edited the text for brevity and consistency, so please pardon any
 errors I may have introduced in the process.  Thanks go entirely to the
 original posters of these messages - I've done nothing but copy their
 work.


 ********************************************************************
 From: [e-mail]
 Organization: IBM Boca Programming Center
 Date: Wed, 27 Jan 93 23:53:32 GMT

 Install the NetWare requester. Then install LAN Adapter Protocol Support
 (LAPS). This came with your TCP/IP disks. Choose NetWare Requester
 support if it is available. Next install TCP/IP Support.

 If your version of LAPS offered NetWare requester support, double click
 on the NetWare line and a dialog will appear. The first line will be for
 the universal address of your Ethernet card.  Enter that number and exit
 LAPS.  Alternately, you can edit the LANADDRESS = line in
 \IBMCOM\PROTOCOL.INI

 If LAPS did not have NetWare support, you must follow the directions in
 Chapter 6 of the NetWare Requester for OS/2 manual.

 Good luck!


 ********************************************************************
 From: [e-mail] (David L. Burke)
 Organization: UNC Educational Computing Service
 Date: Mon, 25 Jan 1993 23:54:56 GMT

 Hope this stuff helps, guys.  It was a bitch, but I got Requester to
 work with TCP/IP for OS/2 1.2.1.  Below are The Big Three:  CONFIG.SYS,
 NET.CFG, and PROTOCOL.INI.

 Before I say anything else, I hope to hell that after making these
 changes that your machine doesn't boot up with a register dump or some
 stupid message like "unable to locate Country.sys," or anything else
 which stops you in your tracks.  Please make sure you have a floppy boot
 disk handy (I prefer makeboot.cmd myself.)  Good luck.

 General points:  Don't let ICAT or LAPS alter your config.sys.  Add the
 appropriate lines and include \TCPIP... and \IBMCOM...  in the necessary
 path statements.

 Setup:  I'm using an NE2000 NIC (there's a NE2000.NIF on hobbes for
 LAPS).  This setup works with 2.1b (as long as OS/2 is not loaded on
 Drive E: for some wierd reason).  I'm superstitious about the INET.SYS
 and IFNDIS.SYS files, making sure I use the same ones with each new
 install.  Don't have any idea why that is though.

 * * * * * *
 * CONFIG.SYS  (Notice that all the TCPIP and IBMCOM stuff is at the end of
 *             the file, after the requester stuff.)
 * * * * * *
 IFS=D:\OS2\HPFS.IFS  /CACHE:512 /CRECL:4 /AUTOCHECK:D
 PROTSHELL=D:\OS2\PMSHELL.EXE
 SET USER_INI=D:\OS2\OS2.INI
 SET SYSTEM_INI=D:\OS2\OS2SYS.INI
 SET OS2_SHELL=D:\OS2\CMD.EXE
 SET AUTOSTART=PROGRAMS,TASKLIST,FOLDERS,CONNECTIONS
 SET RUNWORKPLACE=D:\OS2\PMSHELL.EXE
 SET COMSPEC=D:\OS2\CMD.EXE
 LIBPATH=.;D:\OS2\DLL;D:\OS2\MDOS;D:\;D:\OS2\APPS\DLL;D:\NETWARE;
 D:\TCPIP\DLL;D:\IBMCOM\DLL;D:\TALKTHRU\PROGRAMS;
 SET PATH=D:\OS2;D:\OS2\SYSTEM;D:\OS2\MDOS\WINOS2;D:\OS2\INSTALL;
 D:\;D:\OS2\MDOS;D:\OS2\APPS;L:\OS2;P:\OS2;D:\NETWARE;D:\TCPIP\BIN;
 D:\IBMCOM;d:\tools\utilities;D:\TALKTHRU\PROGRAMS;
 SET DPATH=D:\OS2;D:\OS2\SYSTEM;D:\OS2\MDOS\WINOS2;D:\OS2\INSTALL;
 D:\;D:\OS2\BITMAP;D:\OS2\MDOS;D:\OS2\APPS;D:\NETWARE;D:\IBMCOM;
 SET PROMPT=$i[$p]
 SET HELP=D:\OS2\HELP;D:\OS2\HELP\TUTORIAL;D:\TCPIP\HELP;
 SET GLOSSARY=D:\OS2\HELP\GLOSS;
 SET IPF_KEYS=SBCS
 PRIORITY_DISK_IO=YES
 FILES=20
 SET DIRCMD=/O:GN
 DEVICE=D:\OS2\TESTCFG.SYS
 DEVICE=D:\OS2\DOS.SYS
 DEVICE=D:\OS2\PMDD.SYS
 BUFFERS=30
 IOPL=YES
 DISKCACHE=512,LW
 MAXWAIT=3
 MEMMAN=SWAP,PROTECT
 SWAPPATH=D:\OS2\SYSTEM 2048 2048
 BREAK=OFF
 THREADS=256
 PRINTMONBUFSIZE=134,134,134
 COUNTRY=001,D:\OS2\SYSTEM\COUNTRY.SYS
 SET KEYS=ON
 REM SET DELDIR=C:\DELETE,512;D:\DELETE,512;
 BASEDEV=PRINT01.SYS
 BASEDEV=IBM1FLPY.ADD
 BASEDEV=IBM1S506.ADD
 BASEDEV=OS2DASD.DMD
 SET BOOKSHELF=D:\OS2\BOOK
 SET EPMPATH=D:\OS2\APPS
 SET FAXPM=D:\OS2\APPS
 REM DEVICE=D:\OS2\APPS\SASYNCDA.SYS
 PROTECTONLY=NO
 SHELL=D:\OS2\MDOS\COMMAND.COM D:\OS2\MDOS /P /E:1024
 FCBS=16,8
 RMSIZE=640
 DEVICE=D:\OS2\MDOS\VEMM.SYS
 DOS=LOW,NOUMB
 DEVICE=D:\OS2\MDOS\VDPX.SYS
 DEVICE=D:\OS2\MDOS\VXMS.SYS /UMB
 DEVICE=D:\OS2\MDOS\VDPMI.SYS
 DEVICE=D:\OS2\MDOS\VWIN.SYS
 DEVICE=D:\OS2\MDOS\VCDROM.SYS
 REM DEVICE=D:\OS2\PCMCIA.SYS
 REM DEVICE=D:\OS2\MDOS\VPCMCIA.SYS
 DEVICE=D:\OS2\MDOS\VMOUSE.SYS
 DEVICE=D:\OS2\POINTDD.SYS
 DEVICE=D:\OS2\MOUSE.SYS SERIAL=COM1
 DEVICE=D:\OS2\COM.SYS
 DEVICE=D:\OS2\MDOS\VCOM.SYS
 CODEPAGE=437,850
 DEVINFO=KBD,US,D:\OS2\KEYBOARD.DCP
 SET VIDEO_DEVICES=VIO_SVGA
 DEVICE=D:\OS2\MDOS\VSVGA.SYS

 REM --- NetWare Requester statements BEGIN ---
 DEVICE=D:\NETWARE\LSL.SYS
 RUN=D:\NETWARE\DDAEMON.EXE
 DEVICE=D:\NETWARE\NE2000.SYS
 DEVICE=D:\NETWARE\IPX.SYS
 DEVICE=D:\NETWARE\SPX.SYS
 RUN=D:\NETWARE\SPDAEMON.EXE
 rem DEVICE=D:\NETWARE\NMPIPE.SYS
 rem DEVICE=D:\NETWARE\NPSERVER.SYS
 rem RUN=D:\NETWARE\NPDAEMON.EXE NP_COMPUTERNAME
 DEVICE=D:\NETWARE\NWREQ.SYS
 IFS=D:\NETWARE\NWIFS.IFS
 RUN=D:\NETWARE\NWDAEMON.EXE
 DEVICE=D:\NETWARE\NETBIOS.SYS
 RUN=D:\NETWARE\NBDAEMON.EXE
 DEVICE=D:\NETWARE\VIPX.SYS
 DEVICE=D:\NETWARE\VSHELL.SYS
 REM --- NetWare Requester statements END ---

 REM  Below is all the TCPIP and IBMCOM stuff (not before!)
 DEVICE=D:\IBMCOM\LANMSGDD.OS2 /I:D:\IBMCOM
 DEVICE=D:\IBMCOM\PROTMAN.OS2 /I:D:\IBMCOM
 rem  DEVICE=D:\IBMCOM\MACS\NE2000.OS2 /I:D:\IBMCOM

 DEVICE=D:\NETWARE\ODINSUP.SYS
 RUN=D:\IBMCOM\PROTOCOL\NETBIND.EXE
 RUN=D:\IBMCOM\LANMSGEX.EXE

 SET ETC=D:\TCPIP\ETC
 SET TMP=D:\TCPIP\TMP
 DEVICE=D:\IBMCOM\PROTOCOL\IFNDIS.SYS
 DEVICE=D:\IBMCOM\PROTOCOL\INET.SYS
 RUN=D:\TCPIP\BIN\CNTRL.EXE

 SET VIO_SVGA=DEVICE(BVHVGA,BVHSVGA)
 DEVINFO=SCR,VGA,D:\OS2\VIOTBL.DCP


 * * * * * *
 * NET.CFG  (nothing special here)
 * * * * * *
 Link driver ne2000
    protocol ipx 8137 ethernet_ii
    frame ethernet_ii
    int 5
    port 360
    node address 1B198826

 netware requester
     preferred ecu_joyner_library

 protocol odinsup
     bind ne2000

 link support
     buffers 16 1514


 * * * * * *
 * PROTOCOL.INI (Don't worry about the LAPS settings during install.  They
 *               only write to the PROTOCOL.INI as far as I know.)
 * * * * * *
 [PROT_MAN]
  DriverName = PROTMAN$

 [IBMLXCFG]
  NE2000_nif = NE2000.nif
  TCPIP_nif = TCPIP.nif

 ;*----------------------------------------------*
 ;*------------- PROTOCOL SECTION ---------------*
 ;*----------------------------------------------*

 [TCPIP_nif]
  DriverName = TCPIP$
 ; Bindings = NE2000_nif
  Bindings = NE2000

 ;*----------------------------------------------*
 ;*--------------- MAC SECTION ------------------*
 ;*----------------------------------------------*

 [NE2000]

 [NE2000_nif]
  DriverName = MS2000$
  IOBASE = 0x360
  INTERRUPT = 5


 ********************************************************************
 From: [e-mail] (Don Loflin)
 Organization: The University of Texas at Austin, Austin, Texas
 Date: 28 Jan 1993 08:55:21 -0600

 I found the following settings to be the most crucial, especially the
 "protocol odinsup / bind ne2000" part, which the ODINSUP readme claimed
 was optional if you only had 1 ODI driver loaded (e.g. it would bind to
 the only driver found).

 * * * * *
 * NET.CFG
 * * * * *
 protocol odinsup
     bind ne2000

 * * * * *
 * PROTOCOL.INI
 * * * * *
 [TCPIP_nif]
  Bindings = NE2000


 ********************************************************************
 From: [e-mail] (Helmut Meyhoefer)
 Organization: Computing Center
 Date: Thu, 28 Jan 1993 13:38:27 GMT

 This is my configuration for CM, TCPIP and NW Requester with NSD201.  No
 problems.

 * * * * *
 * CONFIG.SYS
 * * * * *

 IFS=C:\OS2\HPFS.IFS /CACHE:384 /CRECL:4 /AUTOCHECK:CDE

 REM ******* LAPS:
 RUN=C:\OS2\INSTALL\IBMLANLK.EXE C:\OS2\INSTALL\IBMLANLK.LST

 RUN=C:\OS2\XCOPY.EXE C:\OS2\OS2*.INI E:\OS2\IniSave
 PROTSHELL=C:\OS2\PMSHELL.EXE
 SET RESTARTOBJECTS=STARTUPFOLDERSONLY
 SET USER_INI=C:\OS2\OS2.INI
 SET SYSTEM_INI=C:\OS2\OS2SYS.INI
 SET OS2_SHELL=C:\OS2\CMD.EXE
 SET AUTOSTART=PROGRAMS,TASKLIST,FOLDERS
 SET RUNWORKPLACE=C:\OS2\PMSHELL.EXE
 SET COMSPEC=C:\OS2\CMD.EXE
 LIBPATH=.;C:\OS2\DLL;C:\MUGLIB\DLL;C:\OS2\MDOS;E:\CMLIB\DLL;C:\;C:\OS2\APPS\DLL
 ;C:\IBMCOM\DLL;E:\NETWARE;E:\TCPIP\DLL;
 SET
 PATH=C:\OS2;C:\OS2\CMD;C:\MUGLIB;C:\OS2\SYSTEM;D:\SYSTEM;C:\OS2\MDOS\WINOS2;E:\
 CMLIB;E:\CMLIB\APPN;C:\OS2\INSTALL;C:\;C:\OS2\MDOS;C:\OS2\APPS;L:\OS2;P:\OS2;E:
 \NETWARE;E:\TCPIP\BIN;
 SET
 DPATH=C:\OS2;C:\MUGLIB\DLL;E:\CMLIB;E:\CMLIB\APPN;C:\OS2\SYSTEM;C:\OS2\MDOS\WIN
 OS2;C:\OS2\INSTALL;C:\;C:\OS2\BITMAP;C:\OS2\MDOS;C:\OS2\APPS;C:\IBMCOM;E:\NETWA
 RE;L:\OS2;
 SET PROMPT=$e[32;40m$e[1mrc=$r [$p] $i$e]0m
 SET HELP=E:\CMLIB\APPN;C:\OS2\HELP;C:\OS2\HELP\TUTORIAL;E:\TCPIP\HELP;
 SET GLOSSARY=C:\OS2\HELP\GLOSS;
 SET THE_HELP=D:\OS2\UTILS\THE\OS2.HLP
 SET THE=D:\OS2\UTILS\THE\PROFILE.THE
 SET DIRCMD=/O:GN
 PRIORITY_DISK_IO=YES
 FILES=20
 DEVICE=C:\OS2\R0CSDD.SYS

 REM ******* LAPS:
 DEVICE=C:\OS2\INSTALL\IBMLANLK.SYS C:\OS2\INSTALL\IBMLANLK.LST
 DEVICE=C:\IBMCOM\LANMSGDD.OS2 /I:C:\IBMCOM
 DEVICE=C:\ibmcom\protman.os2 /I:C:\ibmcom

 DEVICE=C:\OS2\TESTCFG.SYS
 DEVICE=C:\OS2\DOS.SYS
 DEVICE=C:\OS2\PMDD.SYS
 BUFFERS=30
 IOPL=YES
 DISKCACHE=64,LW
 MAXWAIT=3
 MEMMAN=SWAP,PROTECT
 SWAPPATH=E:\SWAPSPACE 2048 4096
 BREAK=OFF
 THREADS=256
 PRINTMONBUFSIZE=134,134,134
 COUNTRY=049,C:\OS2\SYSTEM\COUNTRY.SYS
 SET KEYS=ON
 SET DELDIR=C:\DELETE,512 D:\DELETE,1024 E:\DELETE,1024
 BASEDEV=PRINT02.SYS
 BASEDEV=IBM2FLPY.ADD
 BASEDEV=IBM2ADSK.ADD
 BASEDEV=OS2DASD.DMD
 SET BOOKSHELF=C:\OS2\BOOK;
 SET EPATH=C:\OS2\APPS
 DEVICE=C:\OS2\APPS\SASYNCDB.SYS
 PROTECTONLY=NO
 SHELL=C:\OS2\MDOS\COMMAND.COM C:\OS2\MDOS /E:1000/P
 FCBS=16,8
 RMSIZE=640
 DEVICE=C:\OS2\MDOS\VEMM.SYS
 DEVICE=C:\OS2\MDOS\VMOUSE.SYS
 DOS=LOW,NOUMB
 DEVICE=C:\OS2\MDOS\VDPX.SYS
 DEVICE=C:\OS2\MDOS\VXMS.SYS /UMB
 DEVICE=C:\OS2\MDOS\VDPMI.SYS
 DEVICE=C:\OS2\MDOS\VWIN.SYS
 DEVICE=C:\OS2\MDOS\VCDROM.SYS
 DEVINFO=SCR,VGA,C:\OS2\VIOTBL.DCP
 SET VIDEO_DEVICES=VIO_VGA
 SET VIO_VGA=DEVICE(BVHVGA)
 DEVICE=C:\OS2\MDOS\VVGA.SYS
 CODEPAGE=850,437
 DEVINFO=KBD,GR,C:\OS2\KEYBOARD.DCP
 DEVICE=C:\OS2\POINTDD.SYS
 DEVICE=C:\OS2\MOUSE.SYS
 DEVICE=C:\OS2\COM.SYS
 DEVICE=C:\OS2\MDOS\VCOM.SYS
 DEVICE=C:\OS2\MDOS\ANSI.SYS

 REM Protokollierung einschalten:
 DEVICE=C:\OS2\LOG.SYS
 RUN=C:\OS2\SYSTEM\LOGDAEM.EXE

 REM ********* Netware Requester ***************
 REM --- NETWARE REQUESTER STATEMENTS BEGIN ---
 DEVICE=E:\NETWARE\LSL.SYS
 RUN=E:\NETWARE\DDAEMON.EXE
 DEVICE=E:\NETWARE\TOKEN.SYS
 DEVICE=E:\NETWARE\ROUTE.SYS
 DEVICE=E:\NETWARE\IPX.SYS
 DEVICE=E:\NETWARE\SPX.SYS
 RUN=E:\NETWARE\SPDAEMON.EXE
 DEVICE=E:\NETWARE\NWREQ.SYS
 IFS=E:\NETWARE\NWIFS.IFS
 RUN=E:\NETWARE\NWDAEMON.EXE
 DEVICE=E:\NETWARE\VIPX.SYS
 DEVICE=E:\NETWARE\VSHELL.SYS
 DEVICE=E:\NETWARE\ODINSUP.SYS
 REM --- NETWARE REQUESTER STATEMENTS END ---

 REM ********* Communications Manager ***************
 DEVICE=C:\ibmcom\protocol\LANDD.OS2
 DEVICE=C:\ibmcom\protocol\LANDLLDD.OS2
 DEVICE=E:\CMLIB\ACSLDLAN.SYS
 RUN=C:\OS2\EPW.EXE
 RUN=C:\ibmcom\protocol\landll.exe
 DEVICE=E:\CMLIB\APPN\CMKFMDE.SYS
 DEVICE=C:\IBMCOM\PROTOCOL\IFNDIS.SYS
 DEVICE=C:\IBMCOM\PROTOCOL\INET.SYS

 REM ******* TCPIP
 SET ETC=E:\TCPIP\ETC
 SET TMP=E:\TCPIP\TMP
 RUN=E:\TCPIP\BIN\CNTRL.EXE

 REM ******* LAPS:
 RUN=C:\ibmcom\protocol\netbind.exe
 RUN=C:\ibmcom\lanmsgex.exe

 REM ******* TCPIP
 SET XFILES=E:\TCPIP\X11
 SET USERNAME=
 SET HOSTNAME=
 SET TELNET.PASSWORD.ID=

 CALL=CMD.EXE


 * * * * *
 * NET.CFG
 * * * * *

 Link Driver token
    frame token-ring
    frame token-ring_snap
    node address 400031741015

 Link Support
    buffers 14 4210

 protocol odinsup
    bind token

 protocol stack ipx
    sessions 50
    Sockets 64

 PROTOCOL STACK SPX
    Abort Timeout 30000
    Verify Timeout 3000
    Listen Timeout 6000
    Send Timeout 6000
    Retry Count 20
    Sessions 50

 Netware Requester
    cache buffers 20
    sessions 8
    request retries 20
    preferred server server_name

 Netware Spooler
    copies 1
    keep
    size 8
    banner
    form feed


 * * * * *
 * PROTOCOL.INI
 * * * * *

 [PROT_MAN]
  DriverName = PROTMAN$

 [IBMLXCFG]
  TCPIP_nif = TCPIP.nif
  LANDD_nif = LANDD.NIF

 [TCPIP_nif]
  DriverName = TCPIP$
  Bindings = TOKEN

 [LANDD_nif]
  DriverName = LANDD$
  Bindings = TOKEN


 ********************************************************************
 From: [e-mail] (Roger de Reus)
 Organization: Mikroelektronik Centret, DTH, Denmark
 Date: Thu, 10 Jun 93 12:11:44 METDST

 One suggestion for your document: Since you refer to ftp.nmsu.edu to
 get the CSD's for TCP/IP, you may as well refer to the same place to
 get the latest Netware release (/pub/os2/2_x/network/novell) and
 documentation.

 Here the (excerpts) of the configuration files. I have TCP/IP (with
 X11) and Netware (finally) running simultaneously over one single 3COM
 3C503 card. I did not use the configuration programs (ICAT and LAPS)
 but manually edited the files. Note that all the ELINKII stuff is
 commented out. I was happy when things  finally worked out, and did not
 try more. Probably  lots  of  extraneous code lying around. Did not get
 things running  by  automatically routing, so explicitly added a
 default gateway in  the  routing command (last line of this file).

 Hope this will get some people getting ahead quicker  than  I did.
 Credits   should   go   to   the   Hobbes   ftp    server
 (ftp-os2.nmsu.edu) which made the latest changes to both  TCP/IP and
 Netware software available (and now supplies  all  the  OS/2 goodies on
 CD-ROM for $25,-, I believe---grab  it  you  American guys), Kerry
 Sesker ([e-mail])  who  supplied me with some
 configuration files I could start with,  and  Prof.  Mike Thompson
 (Cornell University), who pointed  me  to  ftp-os2 for the Novell
 software update.
 ________________________________________________________________/\_____
 Roger de Reus ([e-mail])                                 \/
                                  Mikroelektronik Centret  /\ /\ /\  /--
 Ph. ([phone]          DTH, bldg. 345-east  -- -- -- ----
 Ph. ([phone]                    DK--2800 Lyngby  -- -- -- ----
 Fax [phone]                            Denmark  -- -- --  `--
 _______________________________________________________________________

 * * * * *
 * CONFIG.SYS (relevant parts)
 * * * * *

 LIBPATH=...;C:\TCPIP\DLL;C:\USR\NETWARE;C:\IBMCOM\DLL;
 SET PATH=...;C:\TCPIP\BIN;...;C:\USR\NETWARE;C:\IBMCOM;
 SET DPATH=...;C:\USR\NETWARE;C:\IBMCOM;
 SET HELP=...;C:\TCPIP\HELP;

 REM --- TCP/IP and NetWare Requester statements BEGIN ---
 DEVICE=C:\IBMCOM\PROTMAN.OS2 /I:C:\IBMCOM
 DEVICE=C:\IBMCOM\LANMSGDD.OS2 /I:C:\IBMCOM
 SET ETC=C:\TCPIP\ETC
 RUN=C:\TCPIP\BIN\CNTRL.EXE
 SET XFILES=C:\TCPIP\X11
 SET DISPLAY=reus026.mic.dth.dk:0
 SET TZ=CET
 SET LPR_SERVER=mic.dth.dk
 SET LPR_PRINTER=ps
 SET HOSTNAME=reus026
 SET LANG=Da_DK
 SET NWLANGUAGE=ENGLISH
 DEVICE=C:\USR\NETWARE\LSL.SYS
 RUN=C:\USR\NETWARE\DDAEMON.EXE
 DEVICE=C:\USR\NETWARE\3C503.SYS
 DEVICE=C:\USR\NETWARE\ODINSUP.SYS
 DEVICE=C:\USR\NETWARE\IPX.SYS
 DEVICE=C:\USR\NETWARE\NWREQ.SYS
 IFS=C:\USR\NETWARE\NWIFS.IFS
 RUN=C:\USR\NETWARE\NWDAEMON.EXE
 RUN=C:\IBMCOM\PROTOCOL\NETBIND.EXE
 RUN=C:\IBMCOM\LANMSGEX.EXE
 DEVICE=C:\USR\NETWARE\VIPX.SYS
 DEVICE=C:\USR\NETWARE\VSHELL.SYS
 DEVICE=C:\IBMCOM\PROTOCOL\INET.SYS
 DEVICE=C:\IBMCOM\PROTOCOL\IFNDIS.SYS
 rem DEVICE=C:\IBMCOM\PROTOCOL\ELINKII.OS2
 REM --- TCP/IP and NetWare Requester statements END ---


 * * * * *
 * NET.CFG
 * * * * *

 cache buffers = 40
 file handles = 120
 max tasks = 60
 pb buffers = 10
 preferred server = mic
 show dots on

 link driver 3C503
    frame ethernet_802.3
    frame ethernet_ii
    frame ethernet_802.2
    frame ethernet_snap
    node address 02608c8c04eb
    protocol ipx 0 ethernet_802.3

 link support
    buffers 15 4210
    mempool 4096

 protocol odinsup
    bind 3c503

 protocol stack IPX
    bind 3c503

 protocol tcpip
    ip_address 129.142.64.205
    ip_router  129.142.6.16
    ip_netmask 255.255.0.0
    tcp_sockets 8
    udp_sockets 8
    raw_sockets 1
    nb_sessions 4
    nb_commands 8
    nb_adapter  0
    nb_domain

 netware requestor
    cache buffers 20
    displayharderrors no
    preferred server mic

 netware spooler
    no banner
    no form feed


 * * * * *
 * PROTOCOL.INI
 * * * * *

 [PROT_MAN]
  DriverName = PROTMAN$

 [IBMLXCFG]
 ; ELNKII_nif = ELNKII.nif
  TCPIP_nif = TCPIP.nif

 ;*----------------------------------------------*
 ;*------------- PROTOCOL SECTION ---------------*
 ;*----------------------------------------------*

 [TCPIP_nif]
  DriverName = TCPIP$
  Bindings = X3C503


 ;*----------------------------------------------*
 ;*--------------- MAC SECTION ------------------*
 ;*----------------------------------------------*

 [X3C503]

 ;[ELNKII_nif]
 ; DriverName = ELNKII$
 ; netaddress = "02608C8C04EB"
 ; interrupt = 3
 ; ioaddress = 0x300
 ; transceiver = "ONBOARD"
 ; maxtransmits = 8
 ; xmitbufs = 2


 * * * * *
 * TCPSTART.CMD (initializes also X11)
 * * * * *

 @echo off
 echo CONFIGURING TCP/IP .....
 CALL C:\TCPIP\BIN\SETUP.CMD
 echo ..... FINISHED CONFIGURING TCP/IP
 echo STARTING THE TCP/IP PROCESSES .....
 rem start pmx -nocopyright -staticcolor -k 102
 CALL C:\TCPIP\BIN\XINIT.CMD -staticcolor -k 102
 echo     ..... X System Server Started
 rem call nfsstart
 rem echo     ..... Network File System Client Started
 echo ..... FINISHED STARTING THE TCP/IP PROCESSES
 echo .....  EXITING TCPSTART.CMD  .....


 * * * * *
 * SETUP.CMD (called by TCPSTART)
 * * * * *

 route -fh
 arp -f
 ifconfig lan0 129.142.64.205 netmask 255.255.0.0
 route add default 129.142.6.16 1



 ---------------------------------------------------
 (A2) Appendix II: Supplementary information on SLIP
 ---------------------------------------------------

 Rather than editing matter that I don't fully understand, I've included
 this dialog essentially verbatim.  It is Dave Bolen, author of a SLIP
 driver (alternative to IBM's own) replying to SLIP configuration
 questions from Don Lindbergh.  Dave Bolen's SLIP driver is presently
 still in the testing stage, but users reporting in the
 comp.os.os2.networking newsgroup are uniformly glowing in their reviews
 of it.

 At the time of writing, Bolen's slip driver can be had via anonymous
 FTP from ftp.ans.net in file /pub/misc/slip20a3.zoo.

 In any case, the following notes should give you a _lot_ of information
 about SLIP connections in general, as well as information that may be
 specific to Dave's drivers.


 >From: [e-mail] (Don A.B. Lindbergh)
 Date: Wed, 17 Feb 93 14:04:06 EST
 Message-Id: <[e-mail]>
 X-To: [e-mail]
 Subject: Re: TCP/IP, SLIP, Beat 2.1 Setup Questions (LONG)

 Ok, I'm sending you what Bolen sent me.  He has sent me two replies.
 The first is pretty much *it* as far as what you're probably interested
 in.  It is long and has diagrams :)  The second piece is an attempt at
 further clarification.  I also included the first piece of mail from a
 gentlemen trying to help me put the final piece in place, using
 ROUTED.  I basically haven't been able to get it to work (I think)
 because of:

 1. not much time
 2. incorrect syntax

 There will undoubtably be some more email from him, after which I
 predict the light will shine on me, the angles will sing, and I will
 actually have a full blow slip home system going......

 Oh, near the end of Bolen's first note is an 'off the cuff' 'untested'
 method of using 'arp -s' to 'publish' a network card to do routing.  I
 wasen't able to get this to work for me, it may be I'm doing something
 wrong.  I intend to at least confirm with him that this method *does*
 in fact work.  It seems I will be using either this method or ROUTED as
 getting a static route added for my SLIP subnet may be a hassle (Bolen
 talks about all this).

 So, truthfully, I'm not quite out of the woods yet, but I wanted to
 send you what he sent me, because it seems he has told me pretty much
 everything.  I figured it's better to send you more than you need
 rather than edit it down myself.  If you like, I'll forward what I get
 and wrap it up when I get it really working.  Your stuff was invaluable
 to me when I was trying to get tcp/ip going.

 --Don Lindbergh
 [e-mail]

 _______________________________________________________________________
 >From [e-mail] Mon Feb 15 16:41:48 1993
 To: [e-mail] (Don A.B. Lindbergh)

 >REQUEST FOR HELP, somewhat lengthy.....

 Well, let's see what we can do...

 Warning - your request may have been lengthy, but these answers get
 real long sometimes :-)

 >I'm really unclear on how to setup at home for SLIP.  I've read over
 >EVERY occurance of 'slip' in the TCPINFO doc's, I don't get it....

 Part of the difficulty explaining this sort of stuff is that if you get
 generic enough in your explanation to cover anyone's case, the
 explanation becomes vague enough to be less than helpful :-)

 For example - you don't give any actual IP addresses in your supplied
 office and home configurations, and yet it is likely the actual IP
 addresses (and routing between them) that is the problem.

 So - for these examples, I'll use some explicit IP addresses that we
 use here at ANS - hopefully, it will not be difficult to translate
 their use into your own addresses.

 Let's take the office machine.  In my case, it has two interfaces - an
 ethernet (lan0) and com1 (sl).  The important elements for packet flows
 are the addresses of the interfaces, and the routes that the machine
 has to specific hosts or networks.

 Let's say the office LAN is 147.225.10.x, and my machine has the
 address 147.225.10.18.  Thus, subnet 10 of network 147.225 (a class B
 network) is dedicated to the office ethernet.  There is a default
 router on the office lan, 147.225.10.1, that I should send packets to
 when I don't know where to send them.  The subnet mask for my LAN is
 255.255.255.0.  Also, I have a nameserver at 147.225.10.1.

 Now let's say that I choose subnet 11 for my SLIP connection.  You
 can't give hosts at the far end of the SLIP link an address in subnet
 10 since the rest of your LAN all think that subnet 10 hosts are
 directly connected to the ethernet itself.  (This isn't completely
 true, but it's tricky to work around, so let's say it is true for
 now).  It is possible, as your example showed, to have your office
 machine be 147.225.10.18 on both interfaces, but is often clearer if
 you give it an address in the same subnet as the far end of the link.
 Let's say in my case, I've made the office machine 147.225.11.1 on the
 sl interface, and my home machine is going to be 147.225.11.2.

 Thus, you end up with the following configuration:

               -+-
                |
                |      +----------------+              +--------------+
      LAN       |      | Office Machine |              | Home Machine |
                |      | -- -- -- -- -- |  Phone Line  | -- -- -- --  |
                |      |                | 147.225.11.x |              |
 147.225.10.x   +------| lan0        sl |--------------| sl           |
                |  .18 |                | .1        .2 |              |
                |      +----------------+              +--------------+
                |
               -+-

 Now I don't think you've had a problem getting to this stage of
 everything, even though your addresses may be different.  The next big
 problem is getting packets to flow where you want.

 In this example, hosts on the 147.225.10 network don't have a problem
 talking to one another.  They all know that anything in 147.225.10
 should be on the LAN wire.  They also know a default router at
 147.225.10.1.  If I did a "netstat -r" on your office machine, I would
 find an entry like:

    Office with LAN:

         destination     router          intrf (interface)

         default         147.225.10.1    lan0
         147.225.10.0    147.225.10.18   lan0

 or in other words - packets heading to anything on 147.225.10 would go
 through my local interface to the LAN, lan0, while anything else also
 goes out over lan0, but it gets sent to the 147.225.10.1 host, which
 should know what to do with it.

 That's just the LAN.  Once you start SLIO and create the "sl"
 interface, and ifconfig the appropriate addresses, your routing table
 will look like the following:

    Office with LAN and SLIP:

         destination     router          intrf (interface)

         default         147.225.10.1    lan0
         147.225.10.0    147.225.10.18   lan0
         147.225.11.2    147.225.11.1    sl

 which is the same as before except that traffic for host 147.225.11.2
 will go over the serial interface.  If you use the same address for
 your office machine on lan0 as on sl, the above would be the same
 except the router field would show 10.18 in both the lan0 and sl cases.

 Now, to finish off the scenario, on your home machine all you did is
 configure the sl interface - nothing else is running.  That gives you
 a routing table like the following:

    Home with SLIP:

         destination     router          intrf (interface)

         147.225.11.1    147.225.11.2    sl


 Now, given the differences in IP address, I think that's the state
 you've been able to get to in your experiments.  Or, to add this
 routing information to my original picture, my hosts would look
 configured something like the following:

               -+-
                |
                |      +----------------+              +--------------+
      LAN       |      | Office Machine |              | Home Machine |
                |      | -- -- -- -- -- |  Phone Line  | -- -- -- --  |
                |      |                | 147.225.11.x |              |
 147.225.10.x   +------| lan0        sl |--------------| sl           |
                |  .18 |                | .1        .2 |              |
                |      +----------------+              +--------------+
                |  <-- 147.225.10
                |  <-- default
                |            147.225.11.2 -->      <-- 147.225.11.1
               -+-


 Ok.  Presuming you're still with me :-)  Here's where you begin to run
 into problems.  As long as you are on your office machine, you'll be
 fine.  If you try to send packets to someone on the LAN, the route for
 147.225.10 will work and you'll find them.  If you try to send packets
 to your home machine, it will go out over the serial interface and find
 it.  If you send packets somewhere else, they'll go to the default
 router, which will get them there.  And, since your office machine is
 part of your LAN, packets will find their way back to you since the
 rest of the LAN (and outside networks) know how to reach your
 147.225.10 addresses.  Nameserver stuff will work fine too, since the
 nameservers are presumably on your LAN, so queries are just like other
 LAN traffic.

 The home machine has some problems however.  Once you get SLIP running
 there, you should be able to ping your office machine's address over
 the SLIP link.  In other words, in my example, a "ping 147.225.11.1"
 would work, and I could do things like FTP to the office machine.  But
 that's the only communication that works.

 The problem with other hosts is routing related.  For example, let's
 say that your home host tried to talk to the default router,
 147.225.10.1.  On your home machine you only know how to reach
 147.225.11.1, so when you use the 10.1 address, your home machine
 doesn't know how to get there.  That's where you get the "no route to
 host message".  It is telling you it doesn't know where to send
 packets for hosts other than 147.225.11.1.

 Now that's an easy one to fix.  Add a default route on your home box
 pointing to your office box.  Then, if you try to use an address that
 the home machine doesn't know about, it will still send it to the
 office machine.  The office machine will then either know about it (if
 it's part of 147.225.10, such as your nameserver), or it will forward
 it on to *its* default router, 147.225.10.1.

 This is only part of the problem, however.  That solves the outgoing
 packets from your home machine, but it doesn't fix the case of packets
 coming back in to your home machine.  For example, your home machine
 will now know how to send a packet to the nameserver that you use in
 your office, but the nameserver won't know how to send the packet back
 to the home machine.  The nameserver will know that 147.225.10
 addresses are on the LAN, but it won't know what to do with a
 147.225.11 address.

 There are a few ways to fix this.  What you really need to do is to
 get all the other hosts on your LAN to know that subnet 147.225.11 is
 routed through you, and that they should send packets to you for those
 addresses.  This is not normally practical, however, since a number of
 owners of hosts are involved.

 Another alternative is for everyone to run a routing daemon (such as
 the ROUTED that came with the TCP/IP package), which lets your
 machine announce to the other machines that it has the SLIP route, and
 then they know where to send the packages.  Again, this may not be
 reasonable as everyone may not want to or be able to run a routing daemon.

 Probably the easiest thing for you to do is to get whoever administers
 the default router to add a static route for your SLIP subnet to that
 router.  Then, since everyone else on the LAN defaults to that router,
 when it gets packets for your SLIP host it will forward them back to
 you.  Often, it will also issue a redirect to the hosts telling them
 where they should have really sent the packets.

 So to summarize - your problems are likely twofold.  One, that your
 home host doesn't know to default to the office host for stuff that it
 doesn't have an explicit route to.  And two, that the hosts on the LAN
 (or the outside world for that matter) don't know to use you to reach
 your home host.  You need to solve both of those routing problems
 before you can see packets flowing between your home host and any
 other IP attached host.

 In terms of the configurations you posted:

 >OFFICE MACHINE SETUP.CMD:
 >route -fh
 >arp -f
 >ifconfig lan0 myipaddress netmask 255.255.255.0
 >REM ifconfig lan1
 >REM ifconfig lan2
 >REM ifconfig lan3
 >start slio.exe
 >sliowait
 >ifconfig sl myipaddress otherpcaddress
 >route add default myrouter 1

 This should be fine.  In general, I don't expect your office machine
 would have any problems.  It's the one machine in this whole
 configuration that knows just what is going on, and how to reach
 everyone it needs to reach.

 >HOME MACHINE SETUP.CMD:
 >route -fh
 >arp -f
 >REM ifconfig lan0 myipaddress officeipaddress netmask 255.255.255.0
 >REM ifconfig lan1
 >REM ifconfig lan2
 >REM ifconfig lan3
 >start slio.exe
 >sliowait
 >ifconfig sl myipaddress officeipaddress

 This is fine.

 >route add host officeipaddress officerouter

 You don't need this.  ifconfig'ing sl will automatically add this
 route to your routing tables.  What you do need is a statement:

         route add default officeipaddress 1

 to let the home host pass all other packets through to the office as
 well.

 And you need the office machines (or default router) to know about
 your home address too.

 If this sounds convoluted, it's because it's a lot harder to write
 about and explain than just to do - at least I find it that way.

 If you've stuck with me this far, I'll also throw in a way you can
 cheat with your SLIP address and make the rest of your office LAN
 think your home machine is right on the LAN - thus avoiding the need
 to tell them about routing or get your default router to change.

 Some of this is off the cuff - I don't think I've done this explicitly
 myself yet, although it should work fine.

 What you do first is get another LAN address for your home SLIP machine
 - in my case, let's say it was 147.225.10.19.  You then configure
 everyone just as before, including the default route on your home SLIP
 machine.  You end up with the following:


    Office with LAN and SLIP:

         destination     router          intrf (interface)

         default         147.225.10.1    lan0
         147.225.10.0    147.225.10.18   lan0
         147.225.10.19   147.225.10.18   sl


    Home with SLIP:

         destination     router          intrf (interface)

         default         147.225.10.18   sl
         147.225.10.18   147.225.10.19   sl


 For your office machine, any packets to host 147.225.10.19 (your home
 host) will go over the serial line.  All other packets for 147.225.10
 hosts will go over the LAN interface.  And anything else will be put
 over the LAN interface to the default router also on the LAN.

 For your home machine, packets to your office machine will go over the
 serial interface, and packets to anything else will first be passed to
 your office machine (over the serial interface) for handling.

 Now the only rub is getting machines on the LAN to talk back to your
 home machine.  The problem is that those machines will think (since it
 has a 147.225.10 address) that your home machine is directly connected
 to the LAN.

 What happens on the LAN is that other machines issue ARP (Address
 Resolution Protocol) requests to translate an address (147.225.10.19
 in this case) into a hardware level address (such as a token ring or
 ethernet adapter address).  Packets are then sent over the LAN to that
 hardware address.  For most machines, they answer for their own
 address, and give their hardware address.  Obviously, your home
 machine can't do that in this case since it isn't attached directly to
 the LAN.

 So what you do is tell your office machine to answer for your home
 machine.  You use the "arp" command to "publish" a permanent arp entry
 for your home machine.  The entry will use your office machine's
 hardware address as the arp answer.  Then, other machines in the
 office will use your office machine's hardware address on the LAN when
 sending packets to your home machine - so the packets will end up on
 the office machine.  The office machine will look at the actual IP
 address and recognize that it should go down the serial link to the
 home machine.  This entire process is called "Proxy ARPing", and is
 often supplied as an automatic process in SLIP servers or routers -
 we'd just be doing it in a more manual fashion.

 To set up the arp entry, you need to figure out your hardware address.
 You can either do this by looking at the LANTRAN.LOG file in your LAPS
 directory (normally C:\IBMCOM).  It should have a line like:
         "Adapter 0 is using node address 10005A82501A    (...)"

 Or, check someone else's machine that has recently exchanged traffic
 with you and do an "arp -a" and look for your address as in:

         hardware address        IP address
         10005A82501A            147.225.10.18

 In either event, you want to know your 12-digit hexadecimal hardware
 address.  Once you know that, you can stuff an entry for your home
 machine in your arp table with the command:

         arp -s 147.225.10.19 10:00:5A:82:50:1A pub

 which will permanently "publish" an arp entry for your home machine.
 >From now on, other machines on the LAN will think that your home
 machine is right on the ethernet (or token ring) itself, although your
 office machine will actually be routing packets through the serial
 link to the home machine.

 Note that if you are on a token ring, you need to use a bitwise
 reversed address (shown in the LANTRAN.LOG file as the token ring
 format on the same line as the adapter node address).

 I think that's about it.  Like I said - it's more complicated to
 explain than it really is.  I hope this helps more than it confuses.
 I'd suggest also trying to find a local support person at your site
 that may be able to help out with the routing issues.  Or, if you have
 some sort of central SLIP server facility, it will probably be easier
 to make use of that, as the routing issues will most likely have
 already been addressed for that server.

 -- David

 /-----------------------------------------------------------------------\
  \              David Bolen             \  Internet: [e-mail]      /
   |   Advanced Network & Services, Inc.   \   Phone: [phone]   |
  / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: [phone]    \
 \-----------------------------------------------------------------------/

 >From [e-mail] Tue Feb 16 18:37:53 1993
 To: [e-mail] (Don A.B. Lindbergh)
 Subject: Re: TCP/IP, SLIP, Beat 2.1 Setup Questions (LONG)

 Don,

 >                                        I had no idea that the slip
 > connection ip addresses should have a different subnet than the 'real'
 > lan ip addresses.

 Yeah - the problem is that while you can get it partially working
 without using a different subnet, you really need the separate subnet
 for proper operation (barring proxy arp solutions).  The reasons for
 this are rooted in the fundamentals of how IP routing is handled,
 which can be daunting topic for those new to IP networking (or even
 old hands :-)).  Couple this with the fact that most IP office users
 don't necessarily know the subnetting and routing scheme in place at
 their site, and it becomes even more fun.

 (At the risk of repeating info from my previous message)

 I think it starts to become more understandable - and explainable - if
 you make believe you are a machine on your LAN.  Let's say I'm on your
 LAN as address 138.68.31.50.  My machine has a routing table telling
 me where to send packets for particular destinations, as:

    destination 134.68.31.0 gateway 134.68.31.50
         (anything on 134.68.31 goes out onto my local LAN
          via my LAN interface, and gets my LAN address on it
          as the source address)
    destination default gateway 134.68.31.103
         (anything else goes to the specified gateway.  To reach
          that gateway, I use my previous route to reach the LAN)

 Now I'm in good shape - I know how to reach machines on the LAN, and
 those off your LAN.  Now say that friendly Don - you - down the hall
 (with his machine 134.68.31.25) add a SLIP link, and gives your home
 machine address 134.68.31.26.  You sets things up so that if you type
 "ping 134.68.31.50" from home, the packets reach my machine in the
 office.  So far so good - the problem is where do I send the answer?
 I need to reach 134.68.31.26, which according to my routing table is
 right on my LAN.  I therefore try to send it right over the LAN, but
 there's no machine there with that address.

 Now I personally can fix that problem by adding a specific (static)
 route to my machine that says:
         destination 134.68.31.26 gateway 134.68.31.25
 which says that if I need to reach the specific machine 31.26, I send
 it to your office machine.  Anything else in 134.68.31 follows the old
 rule and goes directly to the LAN.  Now I can communicate with
 everyone including your home machine.  Of course, this solution
 doesn't scale well, and it doesn't help you from home since you have
 to get everyone else (or at least the default gateway) to add the
 route.  Thus the rest of my previous note :-)

 >                                   He says getting something like a
 > static route added to our subnet requires calling someone else, which
 > is not a huge problem, but if we did this, hopefully we could add this
 > slip subnet ONCE and that one addition would work for all our group
 > who want to use slip.  I would like to try your suggestions about
 > permanently publishing an arp entry first I think.....

 Having a dedicated SLIP subnet and a primary SLIP router is in fact
 the way many sites (including ours) handles the issue.  For single
 SLIP connections into individual office machines a proxy arp solution
 may be the simplest and most effective - although it does require
 manual configuration - and you still have to get yourself allocated an
 extra address in the LAN subnet.

 > Some further comments and questions....

 Ok.

 > I know, I questioned the wisdom of publicly posting all my ip
 > addresses, on the other hand, who really cares and what if they did
 > right?  I've at least got password entry's for telnet and ftp....

 Actually, that's a pretty prudent idea, and not so strange, especially
 when posting to such a large list.  I don't have much of a problem
 myself as the addresses I've used are protected by a security
 firewall, so external hosts can't reach those subnets of 147.225 anyway.

 Since your address is in fact exposed to the outside world, it's not
 unreasonable to avoid publishing it in such a wide forum.

 > I tried this briefly last night, but apparently it's a whole other
 > lesson to get this damned thing to work.  I don't really understand
 > *who* these manuals are written for.....

 You'd be surprised - the IBM stuff really isn't all that bad when you
 see what else is out there.  Of course, routing daemons are in fact
 another whole world of information, of which ROUTED is one of the
 simplest daemons.  I could start another whole book on handling
 routing daemon issues, but since it's unlikely your entire LAN will
 start listening to RIP broadcasts, I think I'd just bypass this option
 for now.  Even if you do run ROUTED and config everything right, it
 only fixes things for people who are also listening for the
 information that you are then broadcasting.

 > As per my comments earlier, is this something we can do once and will
 > then work for a number of people? ie if we pick subnet 41 for slip,
 > then programmers using slip will be
 >
 > 134.68.41.1
 >          .2
 >          .3 etc?

 It depends on how you are servicing the SLIP connections.  As long as
 there is a single host that is responsible for all of the SLIP users,
 then yes - this will work fine.  For example, here at ANS, we use
 subnet 2 for SLIP - all SLIP users get 147.225.2.x addresses.  Our
 primary machines have a static route for 147.225.2.0 into our Annex
 terminal server (that handles the SLIP users) at 147.225.10.40.

 If however, each user is going to handle his or her own SLIP
 connection into an office machine, it gets a little tricker.  Given
 that changing a centrally administered host is probably harder, what I
 would suggest is telling those responsible for the site router to send
 all SLIP (134.68.41.x) traffic to one particular host - pick someone's
 office machine, or some central machine that you manage.  Then, as
 individual programmers set up SLIP links to a new machine, add a
 static route to the machine you manage for that SLIP link.  Then,
 traffic from LAN or external hosts heading for SLIP home users will
 first go to the central machine you manage, which will then forward it
 on to the appropriate office machine handling the link.  This will
 represent an additional hop, but for the amount of traffic generated
 by SLIP it won't be much.

 Also depending on the central machine of yours, it can send a redirect
 message to the site router, telling it the real machine to send the
 SLIP traffic to.  So it can "learn" to avoid the extra hop.  I'm
 pretty sure that OS/2 (and most Unix platforms) send a redirect by
 default, but don't hold me to that.

 > Ah, here's where it gets fun, this would be a good hack......
 > I'll try this and let you know.  By the way, I keep hearing about your
 > super nifty alternate slip drivers, should I try those?  Dave are you
 > holdin' out on me?  :)  One guy said I could find them at ftp.ans.net

 Well, yes, I do have "super nifty alternate slip drivers" :-) I wasn't
 really holding out on you - getting my drivers wouldn't have solved
 your problem as it was routing and addressing related.  Also, my
 driver is technically alpha code so I don't generally recommend it to
 just anyone yet.  Of course, it's alpha mostly because I'm too
 backlogged to do the final cleanup and call it beta, so it's actually
 quite stable at this point.

 If you're interested - you can anonymously ftp the driver from
 ftp.ans.net in the file /pub/misc/slip20a3.zoo.  This has the driver,
 several utilities, and a readme that should get you up and running.
 My driver both performs better than the standard IBM driver (better
 performance while using less CPU) as well as including support for
 header compression and priority queueing.  This yields better
 interactive performance over a SLIP link.

 The driver does require OS/2 2.0, and TCP/IP 1.2.1 at least at CSD
 level 2252.  (You can always get the latest CSD from ftp-os2 if you
 have an earlier version of TCP/IP - check SYSLEVEL)

 =====================================
 the below is today's first installment from a gent attempting to help me put
 the final piece in place.... ROUTED
 ======================================

 >From [e-mail] Wed Feb 17 13:12:00 1993
 To: [e-mail]
 Subject: Re: TCP/IP, SLIP, Beat 2.1 Setup Questions (LONG)

 I was going to suggest Bolen's stuff.  He is _most_ knowledgeable.

 The secret appears to be as follows:

 The ifconfig statement _must_ have your home ip address and the office
 (slip) machine ip address.  Use a netmask of 255.255.255.0 make sure
 you set the mtu in ifconfig (and in slip.cfg if you use Bolen's
 driver).

 Now: in order to get at any other machine on your office net, you must
 tell your home machine where on the office LAN is the nameserver.  You
 use the OS2 ROUTE command to do this.  What you do in it is to a) clear
 the previous entiries (-fh flag), then b) set up as 'default' the ip
 address of the name server on your office LAN  This means that when at
 the OS2 end you mention a machine on your office lan athat is other
 than the machine to which you are directly connected via slip, the
 request will be routed by your office PC to that name server, which
 will do the address resolution.  The test for connection is to use the
 'ping' command at your home end.

 If you default route to the nameserver, you should be able to ping any
 machine on the internet.  I tested it by pinging local machines here,
 and then finally hobbes.  It replied!

 I'm at the office so I don;t have access to my rexx scripts.  If you
 are still having problemsa, I'll send them to you.

 I agree the manuals are ghastly.  Luckily I have a bunch of Unix TCPIP
 experts here to help me, (we have 4 dept. lans with about 100 Sun
 workstations, 4 file servers, 3 compute servers etc. etc. here)  but
 even they took a while to figure it out.  I asked, but there is no good
 book on TCPIP or X11.  You learn it by recursively reading assorted
 ill-written documents, and asking someone who knows. I've been around
 long enough to have used IBM manuals back in the '50s and '60s, so I'm
 resigned to this situation :-)

 Prof. Donald Jardine, Software Technology Laboratory, Comp. Sci. Dept.,
 Queen's Univ. Kingston Ont. Ph [phone] Fax [phone]


 ------------------------------------
 (A3) Appendix III: Setting up LaMail
 ------------------------------------

 This is a product that I don't use, but [e-mail]
 kindly sent me a document that he prepared for his users there.  I've
 excerpted and edited from that.  Hence I am definitely to blame for
 errors of omission and comission in the following suggestions...

 1.   Installation:  You will want to check off "Sendmail" and "LaMail"
 in the ICAT "Automatic Starting of Services" setup section (see (5)
 section 4. above).

 2.  Customize your LaMail configuration: In the LaMail screen, select
 Options/Set Note Options, then:

     Personal Options
         1. Your login or userid (e.g. dean)
         2. Your hostname (e.g. fiddler.biol.scarolina.edu)
     Note Header
         1. Check "Add Subject Line"
         2. Recommend checking "Long Address Format"
     Note Options
         1. Signature file: You can create a plain-text file that
            contains some address information about yourself.  It will
            be automatically appended to your outgoing mail.  For an
            example, see the three lines at the end of section (0) of
            this document (that's my .signature file contents).  At this
            point, enter the name of the plain-text file that holds your
            signature information.

 3.  Send some test mail: Send some mail to someone who's email address
 you are sure will work.  Ask them to send you a reply.  It may be
 helpful if you are in adjoining offices so you can ask each other if it
 worked...

 4.  Delivery notification: There's no such thing as registered mail
 with SMTP (the mail services that Internet mail uses).  But sometimes
 if mail cannot be sent to the recipient, LaMail will pop-up with the
 rejected mail item.

 5.  Note editor:  The LaMail editor is built upon the OS/2 Enhanced
 Editor (EPM).  Most users would be more familiar with the OS/2 System
 Editor.  To configure the LaMail editor to resemble the System Editor
 more closely do the following while editing a note:

     Select: Options/Preferences:
         Deselect: Advanced Marking
         Select:   Stream Editing
     Select: Options/Save

 6.  How to forward a note:  While you are reading/editing a note (i.e.
 the box title begins "Note") hit Ctrl-I.  In the command dialog box,
 either click on an existing command in the top half (if there are any
 shown) or type a forward command in the lower half (e.g.  FORWARD
 [e-mail]).  Edit the command in the bottom half
 and then select OK.  This will bring up a standard LaMail Create Note
 menu with the forwarded note included.  Edit the subject and other
 header lines as usual and select Send to actually forward the mail.
 LaMail will keep a copy of the command in its history file for the next
 time you select the command option.

 7.  Spelling check:  To check the spelling of an outgoing note, select
 the Options/Proof menu item.  Note that the spelling checker appears to
 have some bugs.  Sometimes it gets confused and flags even common words
 (e.g. "is").  At other times, it appears to just hang.  You may want to
 verify the location of the following LaMail files by choosing the
 Options/Preferences/Settings/Paths menu:

     US dictionary (normally \tcpip\bin\us.dct)
     Personal dictionary

 8.  Folders:  At installation, the ALL folder is the default folder for
 notes.  A copy of your outgoing mail is automatically stored in the
 default folder.  You can create multiple folders (e.g., and OUT folder
 or organize folders by subject).  You can also associate folders with
 individuals in your NICKNAME.NAM file.  Within each folder, the
 appearance of mail items can be customized (color and order of fields,
 etc.).  Each folder can have a distinct icon associated with it.
 Create the icons using the OS/2 icon editor and save them in
 \tcpip\lamail as xxxxxx.ICO where xxxxxx is the name of the folder that
 you want associated with the icon.

 9.  Sendmail:  Sendmail is the background process to LaMail that
 actually sends and receives SMTP messages.  This normally should be
 running all the time, although it can (and probably should) be
 minimized on the screen.  In general, there is nothing you can do in
 this session.  If you need to shut sendmail down, you can terminate it
 by switching to that session and hitting Ctrl-C.  This will bring you
 back to the OS/2 command prompt where you  can type EXIT to close the
 session.

 10. Join some mailing lists:  The Internet has hundreds of mailing
 lists on every conceivable topic.  Good ones include ietf-announce (for
 Internet Task Force announcements), the OS/2 mailing lists, new-list (a
 mailing list that announces new mailing lists!), and many other
 computer and non-computer-specific lists.  The Internet master list of
 mailing lists can be retrieved via anonymous FTP from ftp.nisc.sri.com
 as netinfo/interest-groups.  Because this is such a large file (over
 one million bytes uncompressed), it should be retrieved only on an
 exception basis.  Do NOT print the mailing list index.

 11. Be sure to include your Internet mailing address on your
 correspondence and business cards.  Because many recipients may not be
 entirely familiar with internetwork addressing, and may have accounts
 on alternate services (MCI, Genie, etc.), make sure to be explicit.
 Tell them that it is an Internet address and be sure to give your
 entire address.  For example, I'd give the following information:

     Internet: [e-mail]




 --
 N. Dean Pentcheff
 Biological Sciences, Univ. of South Carolina, Columbia SC 29208 (803-777-8998)
 Internet addresses: [e-mail] or [e-mail]
 Getting started with OS/2 networking using IBM's TCP/IP software